Java 2 Enterprise Edition (J2EE) applications, for example those developed with WebLogic Server, are packaged in a standard way, defined by the J2EE specifications. J2EE defines component behaviors and packaging in a generic, portable way, postponing run-time configuration until the component is actually deployed on an application server. J2EE includes deployment specifications for Web applications, EJB modules, enterprise applications, client applications, and resource adapters. J2EE does not specify how an application is deployed on the target server—only how a standard component or application is packaged.
For each component type, the specifications define the files required and their location in the directory structure. Components and applications may include Java classes for EJBs and servlets, resource adapters, Web pages and supporting files, XML-formatted deployment descriptors, and JAR files containing other components. An application that is ready to deploy on, for example WebLogic Server contains additional, WebLogic-specific deployment descriptors and, possibly, container classes generated with the WebLogic EJB, RMI, or JSP compilers.
A file created with the Java jar tool bundles the files in a directory into a single Java ARchive (JAR) file, maintaining the directory structure. The Java classloader can search for Java class files (and other file types) in a JAR file the same way that it searches a directory in its classpath. Because the classloader can search a directory or a JAR file, a developer can deploy J2EE components on WebLogic Server in either an “exploded” directory or a JAR file. JAR files are convenient for packaging components and applications for distribution. They are easier to copy, they use up fewer file handles than an exploded directory, and they can save disk space with file compression. If the Administration Server manages a domain with multiple WebLogic Servers, the developer can only deploy JAR files, because the Administration Console does not copy expanded directories to managed servers.
XML Deployment Descriptors
Components and applications have deployment descriptors-XML documents-that describe the contents of the directory or JAR file. Deployment descriptors are text documents formatted with XML tags. The J2EE specifications define standard, portable deployment descriptors for J2EE components and applications. BEA defines additional WebLogic-specific deployment descriptors required to deploy a component or application in the WebLogic Server environment.
Packaging Enterprise Applications
An Enterprise archive contains EJB and Web modules that are part of a related application. The EJB and Web modules are bundled together in another JAR file with an .ear extension. The META-INF subdirectory in an .ear file contains an application.xml deployment descriptor from Sun, which identifies the modules packaged in the ear file. A supplemental deployment descriptor, weblogic-application.xml contains additional WebLogic-specific deployment information. Within application.xml, a developer can define items such as the modules that make up your application and the security roles used within the application.
When the application is deployed the necessary resources must also be deployed. The traditional method is to modify the global Java Naming Directory Interface (JNDI) tree. The Java Naming Directory Interface (JNDI) provides naming and directory functionality for the system, and allows applications to perform standard directory operations. JNDI is the primary mechanism by which applications store and retrieve Java objects, and is typically independent of any specific implementation. In the JNDI tree, the application environment comprises a number of subtrees or subcomponents of the global JNDI tree, and is initialized as part of the system startup process. However, one of the problems with this traditional method of global JNDI and its use in application packaging and deployment is that it typically involves the input of a system administrator to configure the application to properly run within the global environment. Typically, the administrator accomplishes this configuration process using a configuration tool in which they modify the global JNDI tree. As additional new applications are added to the system, they must be specified in this way. The overall result is a lot of changes at the system-wide or global level, and increased burden for the software developer and/or administrator.